1. Field of the Invention
The invention relates to distributed processing systems. More particularly, the invention relates to methods and apparatus for distributing processing tasks between a real-time host processor and at least one object oriented processor, such as an I/O processor, wherein the host processor is substantially relieved of real time interrupts.
2. State of the Art
Early ("batch mode") data processors operated with peripheral devices in a strictly sequential manner governed by a sequential software program. For example, a software program instructed the central processor to control a card reader to sequentially read input from punched cards. The input was sequentially manipulated according to the program and the processor was instructed to control a line printer to print output one line at a time in a sequential manner. At no time did two peripheral devices attempt to operate simultaneously.
Modern ("real time" or "multi-tasking") computers permit seemingly simultaneous operation of peripherals by interrupting the processor periodically to control several peripheral devices. For example, as a user types on a keyboard, the input from this peripheral to the processor is seemingly simultaneously displayed by the processor on a video display peripheral. In reality, the processor is interrupted periodically from displaying output on the video display in order to obtain input from the keyboard. It is only because the processor operates at a very high speed that there is an illusion of simultaneity. In a more complex processing system, there may be several peripherals vying for processor attention at any time. For example, in a desktop multimedia computer, several peripheral devices must be controlled by the processor in a seemingly simultaneous manner in order to produce the proper results. The peripheral devices in this system might include a CD-ROM drive, a hard disk drive, a color video display, a stereo sound card, a keyboard, and a mouse, a joystick, or a graphics tablet. Moreover, the programming environment in a system baking so many demanding peripheral devices is incredibly complex. The system software must be written to schedule processor attention to each device, assign priority to each device and allow each device to interrupt the processor at appropriate times. The system software must then schedule tasks for the processor in response to the interrupts from various peripheral devices.
The complexity of task scheduling if further complicated by the fact that control of the peripherals is typically at a very low level and on an event by event basis. Each peripheral device is controlled by peeking and poking values stored in a set of registers which is typically unique to each peripheral and which registers are mapped in the memory addressed by the host. Often these memory mapped peripherals flag activity to the host via interrupts. Given the low level at which these peripheral devices require support, interrupts must be serviced by the host in a very time-critical manner. Any delay in the servicing of interrupts can easily cause the system to malfunction.
Prior art FIG. 1 shows a schematic block diagram of a plurality of peripherals 10, 12, 14, 16, 18, 20 coupled to a host processor 22 by an interrupt driven bus 24. Inputs from and outputs to the peripheral devices 10-20 are orchestrated by the host processor 22 under guidance from system software 26 on an event-by-event basis. The software must fully account for each peripheral and how communication with that peripheral is to be handled. This gives rise to complicated task scheduling problems when there are a number of peripheral devices.
Prior art FIG. 2 shows a schematic illustration of the complexity of the host software necessary to handle a plurality of peripheral devices. Separate peripheral I/O handler routines 30 must be written to communicate with each peripheral at a very low level taking into account the register addresses and their content for each individual peripheral. Access to each peripheral must be scheduled in a main task loop 32 so that timely access to each peripheral is achieved. Data to/from each peripheral must be processed at 34 in order to be used with a data processing program 36. From the foregoing, it will be understood that it is difficult to expand the number of peripherals, because each peripheral added to the bus gives rise to new scheduling problems in the host software. Moreover, as the number of interrupt driven devices increases, so does the possibility arise that a coincidence of interrupts (collision) will cause the system to malfunction. In addition, it is possible that data expected to be available by the data processing program is not available because of a scheduling error.
In addition to scheduling problems, software in a multi-tasking (multi-threaded) system is difficult to debug. Single stepping techniques cannot be used because during any single step of the software program, peripherals serviced by interrupt handlers will be non-functional; i.e., any data that the main program was expecting to read or write will be unavailable as only a single thread can be operational during single stepping. Moreover, since peripheral devices typically require that both hardware timing and software execution be synchronized, it is extremely difficult to emulate a system for the purpose of testing and debugging.
The handling of interrupts by the processor is determined in part by the bus protocol and in part by the design of the processor itself. Typically, the bus is designed to work with a particular processor or group of processors; and peripheral devices are designed to work with a particular bus. Moreover, each processor-bus system handles interrupts in a different way. This makes it difficult, if not impossible, to adapt program code used on one processor-bus system for use on another. Thus, simple I/O functions frequently need to be re-engineered for each processor-bus system. For example, a typical "front panel" interface for a computer controlled device may require the use of over sixty peripherals in the form of switches, LEDs, LCDs, rotary encoders, sound output drivers, etc. Functions which might seem superficially simple, such as driving an LED display, can be problematic. In a multiplexed LED display, e.g., the brightness of a particular column is directly proportional to the time the column is active. If this time varies significantly, as it will easily do when driven by a processor subject to a number of interrupts, the display will flicker.
In summary, coupling peripheral devices to a host processor for real-time computing/event handling is problematic for the following reasons: scheduling is difficult, communication with peripherals is tedious and inconsistent, addition of peripherals requires major program changes, debugging is difficult, and code adaptation is difficult. Nevertheless, virtually all real-time processor systems deal with peripherals using this type of memory mapping and interrupt driven bus system where the host is required to service the peripherals on an event-by-event basis. The state of the art solution to dealing with scheduling problems is to provide a faster processor which expedites the execution of the peripheral supervision code and thus reduces the latency between concurrent interrupts simplifying the scheduling task. However, due to the criticality of interrupt scheduling, the finite speed of even the fastest processors, and the limitations of the bandwidth of the bus system, scheduling problems are still the single greatest challenge in the writing of software today. Achieving the most potential from any processor depends to a large degree on programming skill in scheduling tasks in response to interrupts. However, the complexity of even marginally efficient task scheduling is daunting to most developers.
The speed and complexity of real time processor systems also depends on the number of processes being managed by the host processor. For example, if the processor is managing input from a serial communications port, output to a printer, and manipulating a complex data set, even the fastest processor will slow dramatically and the software management of these events will be extremely complex. Even if the input from the communications port is merely being transferred as output to the printer, without manipulation, the host processor must be involved in taking the data from the communications port and then sending it to the printer.
In order to relieve the host processor from performing every task, multiprocessor systems have been proposed. Some multiprocessor systems are successful in dividing tasks among processors when the tasks are well defined. For example, it is not uncommon to divide tasks between a data processor and a signal processor in systems which deal with signals and data in real time. It is more difficult to divide data processing tasks among several data processors. The operating system must decide which tasks will be performed by which processor and must schedule tasks so that processors do not remain idle while waiting for new tasks or while waiting for other processors to complete tasks so as to provide needed results. Consequently, there has been very little success in developing a general purpose multiprocessor system and there is no standard programming language for programming a multiprocessor system.
Throughout the years there have been great advances in software development tools which simplify the writing of computer programs. Perhaps the greatest single improvement in these development tools is the utilization of "object oriented" programming languages such as "Smalltalk". Object oriented programming allows the developer to raise the level of abstraction so that complex problems can be solved at a higher level. The elements that provide for this approach are modules of code each of which is referred to as an "object". These objects can be individually debugged and re-used in other programs to shorten the time it takes to develop software. A developer can assemble a number of objects, each of which performs a specific task needed to complete the larger task performed by the software package and write a program which calls upon these objects in an appropriate order. Nevertheless, when the software accesses hardware, e.g. peripheral devices, the software must be written to "micro-manage" the hardware on an event-by-event basis.